Today there are a variety of computer devices or user devices available to users for running computer applications, processing information, and sharing content and other data. The computer devices include user devices such as personal computers, lap-tops, notebooks desktops, tablets, PDAs (personal digital assistants), smart phones (e.g., the iPhone, Samsung Galaxy, Amazon Kindle and Kindle Fire, etc.), netbooks, and other forms of computer devices. These devices are portable or mobile in varying degrees. Any of them can be part of a mobile communication system that allows communication between different users using their particular devices.
Typically, these devices receive applications, content, and other data by communicating with a central server controlled by a single vendor associated with the particular user device. For example, user devices such as mobile devices manufactured by Apple, such as the iPod iTouch, iPhone, or iPad, typically receive applications, content, and other data by communicating with Apple's central communication server, e.g., iTunes. Similarly, mobile devices running on Google's Android platform typically receive applications, content, and other data by communicating with Google's central server, Google Play (f.k.a. the Android Marketplace), and mobile devices running on Window's Mobile platform receive applications, content, and other data by communicating with Window's central server, the Windows Marketplace.
Mobile communications systems typically implement these central communication servers because they provide a single point of distribution for users to receive applications, content, and other data compatible with their particular device. While providing a single point of distribution ostensibly simplifies the process of searching for and downloading applications (“apps”), content, or data, these central server systems can make it difficult for third party vendors to distribute a suite of apps and, more generally, to control and direct the distribution and update of their third party vendor apps. Typically, these central communication servers only provide a catalog of applications, content, or data, which are distributed in response to a user's request. Typically, these central communication servers only distribute a single, discrete application, content, or data item; moreover, they require users to search for and locate specific applications, content, or data, one-by-one. Typically, the vendor hosting the central communication server controls how the applications, content, or data are distributed; the third party vendors who originated the application, content, or data, has little or no control over how the application, content, or data is distributed.
For vendors seeking to implement a restricted network for privately distributing proprietary applications, content, or data, these limitations pose several problems. By providing a single point of distribution, central communications servers often do not provide third party vendors a mechanism for restricted network distribution, or otherwise restricted or limited distribution, of applications, content, or data. For example, an organization seeking to distribute an iPhone app to its employees would typically distribute the app through iTunes. However, iTunes does not typically provide a way to target a segment of employees or exclude members of the general public from this app. This makes it difficult for the third party vendors to communicate proprietary or confidential applications, content, or data to users. This also makes it difficult for users themselves to securely communicate proprietary or confidential applications, content, or data to other users within a private network. Accordingly, there is a need for a mobile communications system that provides a restricted network for privately distributing proprietary applications, content, or data to users.
For vendors offering multiple applications, content, or data, these limitations pose several additional problems. Significantly, existing systems using the central communication server approach do not provide for apps to be assembled into a group of related apps that can be downloaded together. By distributing only a single, discrete application, content, or data item, the central communication server burdens the user who must search for and select each component in a group of related apps. Often, these central communication servers contain an overwhelming amount of applications, content, or data, further burdening a user's search process. Moreover, by distributing each component of a group of related apps separately in existing systems, users may have difficulty intuitively identifying which components encompass a given group of apps. Although users may understand that an application, content, or data has originated with a particular third party vendor, users may nevertheless be unable to integrate them into a group as intended by the third party distributor, because the components are distributed separately.
Furthermore, distributing each component in a group of related apps separately complicates the process of updating and maintaining the components encompassed in the group. Whereas third party vendors might prefer to synchronize the updating and maintenance of each component in their group of apps, with a central communications server approach, the user must update or maintain each component individually. Moreover, central server systems are typically under the control of the vendor hosting the server (e.g., Apple or Google). Thus, the amount of control the third party vendors have over their own apps is limited. Normally, the third party vendors do not directly control the distribution of app updates. This often makes it difficult for third party vendors to automatically distribute updates or changes to applications, content, or data.
Central communications servers also complicate the process for third-party vendors and users to communicate applications, content, or data across multiple platforms. For third party vendors to distribute a single application, content, or data item across each platform, the vendor typically distributes the application, content, or data item in every distribution channel. That is, for every device a user owns, the user would typically be required to download an application or file from every central communications server. For example, a vendor seeking to distribute a foreign currency exchange trading software application on iPads, Android Tablets, and Windows Tablets, would typically have the applications distributed separately on iTunes, Google Play, and Windows Marketplace. This burdens users operating multiple devices on different platforms; a user would be required to download the application separately from iTunes, Google Play, and Windows Marketplace. The burden is compounded if the vendor is offering a suite of apps across multiple platforms, as users would be required to download and update multiple applications across multiple platforms.
Another common limitation of existing mobile communication systems is that mobile device operating systems often limit how computer applications share or access content or data with other computer applications. For example, some mobile devices place each software app into a separate “sandbox” at installation time. Designed as a security measure to prevent theft, corruption, or deletion of user data, sandboxes are a set of access controls that limit an app's access to files, resources, or hardware on a mobile device. Sandboxing is a structural system design feature that is common to several operating systems, such as the Google Android™ mobile operating system, the Mozilla Firefox™ OS mobile operating system, the RIM BlackBerry™ mobile operating system, the Apple iOS™ mobile operating system, Nokia Symbian™ or S40™ (Series 40) mobile operating systems, Microsoft's Windows Phone™, Windows 8™, or Windows RT™ operating system, the Samsung Bada™ mobile operating system, the Hewlett Packard webOS™ mobile operating system, the Palm OS™ mobile operating system, the Maemo™ mobile operating system, or the MeeGo™ mobile operating system.
Each app installed on a “sandboxed” mobile device has its own sandbox file directory, which serves as the home for the app and its data. For example, a user may use several discrete mobile applications to manage and analyze his or her stock portfolio. However, because mobile devices fragment memory resources into separate sandboxes, each app may retain a separate, duplicative copy of the user's stock portfolio in its respective sandbox. Accordingly, sandboxed mobile devices limit apps from sharing common data resources. This can be problematic for a party trying to operate a private network employing specialized applications where data-sharing is needed.
Sandboxing further has the disadvantage of inefficiently expending computer resources such as memory, processor power, battery, and bandwidth. For example, redundant copies of portfolio information unnecessarily consume the mobile device's memory. Storing redundant copies of information results in excessive processor power, battery, and bandwidth consumption every time each app updates and synchronizes its local copy of stock portfolio information. Thus, sandboxed mobile devices inefficiently consume computer resources.
As noted above, sandboxed mobile devices typically prevent mobile apps from securely and easily communicating information between apps. Methods exist for passing information parameters between apps through URL schemes. However, these methods generally limit the size and complexity of the information the apps can share; they generally do not enable an app to broadly share information content, files, or documents. Moreover, these methods typically provide little or no security measures to ensure the information is shared in a secure manner.
Another disadvantage to fragmenting mobile apps on a mobile device is the inconvenience users experience when navigating between apps. Even though two apps may be created by the same vendor, users have no convenient way to navigate directly between these apps. Users typically toggle between apps by exiting one app and navigating through home screens on the mobile device to launch another. This can be frustrating to users, and in a business enterprise context, can be inefficient.
Yet another disadvantage to fragmenting mobile apps on a mobile device is the brand inconsistency that results from distributing separate apps. Even though two apps may be created by the same vendor, users may nevertheless perceive the two apps as separate brands because they install, update, and maintain information separately.